home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11748 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: mayne.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 15 Mar 1996 15:09:00 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4ictacINN5gk@mayne.ugrad.cs.ubc.ca>
  8. References: <00001a73+00002504@msn.com> <4iah20$p7k@saba.info.ucla.edu> <4ica32INN5hn@gambier.ugrad.cs.ubc.ca> <4icja9$1r92@saba.info.ucla.edu>
  9. NNTP-Posting-Host: mayne.ugrad.cs.ubc.ca
  10.  
  11. In article <4icja9$1r92@saba.info.ucla.edu>,
  12. Jay Martin <jmartin@cs.ucla.edu> wrote:
  13. >>Lex and Yacc are proven utilities that work. 
  14. >
  15. >Lex and Yacc are braindead crap along with C and Unix.  Do they have an
  16. >option to output Ada??
  17.  
  18. Sorry, I don't know. I have heard of adaptations to other languages. I would
  19. love to try an alternate parser generator to Yacc (other than GNU Bison), but
  20. it is the only one which I can depend to ``always be there''.
  21.  
  22. What does Ada have to do with this? If a parser generator outputs Ada code,
  23. does that make it valid in your eyes or what?
  24.  
  25. >>The input file to Lex is far easier to debug and maintain than a hand-written
  26. >>lexical analyzer.
  27. >>Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar
  28. >>and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the
  29. >>keyboard.
  30. >
  31. >You have become and "idiot savant" at it, congratulations,
  32. >unfortunately the next guy might not reading your code. I wasn't
  33. >talking about needing a grammer, I was talking with about reading in a
  34. >simple table.  Its stupid to bring in two tools with two more
  35. >"languages" to do something trivial that takes a page of normal code.
  36.  
  37. The tools are not required once the code is distilled. They _are_ needed for
  38. its maintenance, though not absolutely essential.
  39.  
  40. Your last sentence is an example of obsolete thinking. I could easily form all
  41. kinds of silly arguments based on the same form: ``It's stupid to do structured
  42. analysis, design and implementation when you can just sit down at the
  43. workstation and hack it out!''; ``It's stupid to re-use code when you can write
  44. from scratch!''; ``It's stupid to use a high-level language when you can code
  45. in assembly language'', and so forth.
  46.  
  47. Let me guess, real programmers enter hexadecimal opcodes directly into memory!
  48.  
  49. Did I detect Ada advocacy coming from you? I must surely have been mistaken...
  50.  
  51. >>A lex generated scanner is far more robust and _faster_ than scanf(),
  52. >you twit, >especially if you use GNU flex -f to generate the scanner.
  53. >>I have written a test program in which I compared a flex scanner against
  54. >>scanf().... 
  55. >
  56. >> System specific performance nonsense deleted.
  57.  
  58. This was not very system specific.  I doubt that the operating system and
  59. hardware could be reorganized in such a way that such a landslide performance
  60. difference could be reversed.  Perhaps with compiler optimization of the
  61. scanf() routine, or a better scanf() implementation.
  62.  
  63. >> Glowing accounts of the wonderfulness of Lex and Yacc deleted.
  64.  
  65. Conveniently so for you. Deletion is not a form of refutation, however. It just
  66. means that you can't find a suitable way to  falsify my claims about how these
  67. tools have helped me  write reliable scanner and parser combinations in minimum
  68. time. Quite unlike your ridiculous claim that using Yacc is done for the sake
  69. of using Yacc and some sort of glory of computer science. Pure bullshit.
  70.  
  71. Yacc gets the job done. Find me a parser generator that's better, and I will
  72. use it. I wouldn't mind one that can do canonical LR(1) rather than LALR(1),
  73. for instance. Also a parser generator that handles some form of attribute
  74. grammar would might also be useful to me in the future.
  75.  
  76. You are obviously a crazed fanatic with a tenuous grip on reality.  I bet the
  77. serious Ada programmers in comp.lang.ada are red with embarrassement due to
  78. their loose association with you.
  79.  
  80. Hatred of Yacc, indeed! Boy, I ought to report you to some animal rights
  81. activists!
  82.  
  83. By the way, there is no such word as ``wonderfulness''. Try ``wonders of ...''.
  84. -- 
  85.  
  86.